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1.0  Introduction 


The  Internet  Protoeol  (IP)  is  genuinely  ubiquitous,  carrying  chats,  documents,  imagery, 
voice  and  video  across  networks  ranging  from  transoceanic  fiber  optic  links  to  wireless 
tactical  mobile  ad-hoc  networks  (MANETs).  The  basic  idea  of  the  Internet  Protocol  is  a 
uniform  interoperability  layer  for  diverse  network  technologies,  as  shown  in  Figure  1.  If  a 
network  technology  can  encapsulate  and  transport  IP  packets  it  can  be  grafted  onto  the 
larger  Internet  and  hosts  connected  to  the  network  can  be  participants  in  the  larger 
Internet.  Upper  layer  protocols  and  applications  can  use  any  sub-network  over  which  IP 
runs. 


Network  service  overlay  protocols- 


Lightweight  virtual  infrastructure 
(global  packet  format,  addressing) 


Subnetworks  (links  encapsulate  IP) 


Figure  1:  Internet  Architecture  "hourglass" 


IP  network  participants  must  adopt  a  common  packet  format  to  allow  routing  amongst  IP 
nodes,  in  particular  devices  called  routers  or  gateways.  Routers  make  decisions  about 
best  or  preferred  states  using  information  available  from  neighbors  in  the  IP  connectivity 
graph,  and  forward  packets  from  their  source  host  to  a  destination  host  using  information 
in  the  packets.  The  source  and  destination  addresses  and  associated  information  are 
contained  in  a  data  structure  called  a  header  (since  it  is  at  the  front  of  the  packet), 
followed  by  a  body  that  contains  the  data  portion  of  the  packet. 

The  dominant  packet  format  in  use  today  is  Version  4  of  the  Internet  Protocol, 
referred  to  as  IPv4.  IPv4  is  characterized  by  32-bit  source  and  destination  addresses. 
Various  schemes  are  used  to  divide  up  this  address  space,  including  a  hierarchy  of  classes 
with  different  allocations  of  the  address  bits  to  network  and  host,  multicast  and  broadcast 
addresses,  non-routable  addresses  and  sub-netting  support  to  further  subdivide  an  address 
according  to  local  needs.  This  32-bit  address  space  was  foreseen  to  be  inadequate  in  the 
early  1990s  and  a  process  began  to  standardize  a  new  version  of  IP  with  128-bit 
addresses  to  avoid  version  changes  forced  by  address  space  run-out  in  the  future.  The 
designers  addressed  a  number  of  other  perceived  shortcomings  of  IPv4  with  new  features 
such  as  integrating  cryptographic  security  mechanisms  and  auto-configuration 
capabilities. 
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Adoption  of  IPv6  has  not  been  as  rapid  as  expeeted  by  its  designers  for  three  primary 
reasons.  First,  deviees  known  as  Network  Address  Translators  (NATs)  beeame  widely 
available  and  deployed,  arguably  as  a  eonsumer  reaetion  to  ISPs  eharging  per-address 
rates.  This  had  the  effeet  of  redueing  pressure  on  the  IP  address  spaee,  as  many  hosts 
eonneeted  to  the  NAT  ean  share  a  single  routable  IP  address.  Seeond,  many  of  the 
pereeived  shorteomings  of  IPv4  were  addressed  with  additional  funetionality  that  was 
retrofitted,  e.g.,  the  Dynamie  Host  Configuration  Protoeol  (DHCP),  whieh  carries  out 
many  of  the  necessary  tasks  for  auto-configuration,  including  allocating  available  IP 
addresses  to  hosts  and  identifying  domain  service  servers  for  hosts.  DHCP,  “leasing” 
addresses,  also  slightly  reduces  address  space  pressure,  relative  to  static  address 
allocations  and  their  lesser  potential  for  reuse.  Third,  a  good  business  case  has  not  yet 
developed;  the  transition  is  perceived  as  cost  with  little  to  no  benefit,  other  than 
addresses,  and  a  “flag  day”  transition  is  potentially  risky  and  disruptive  to  Internet-based 
enterprises. 

This  study  was  undertaken  to  provide  findings  and  recommendations  on  an 
appropriate  stance  towards  IPv6  adoption  by  the  U.S.  Department  of  Defense.  Here, 
when  we  use  the  word  adoption,  we  mean  that  the  protocol  is  the  dominant  protocol  in 
actual  use,  carrying  chats,  charts,  imagery  and  video.  This  is  different  than  deployed, 
which  can  mean  that  the  capability  is  present,  but  unused.  A  primary  concern  of  DoD  is 
the  security  of  networks,  as  the  move  towards  network-centricity  has  made  networking  an 
important  part  of  U.S.  Defense  strategy  and  therefore  an  inviting  target  for  U.S.  military 
adversaries.  Security  analysis  of  IPv6  must  include  analyses  of  host  software  and  training 
to  understand  points  at  which  challenges  might  arise. 

In  carrying  out  this  study,  we  drew  on  our  own  expertise,  performed  experiments,  and 
consulted  technical  experts  at  router  vendors,  security  appliance  vendors,  Internet  service 
providers  and  web  companies.  There  were  several  meetings  with  DoD  elements  that  have 
bearing  on  the  findings  and  recommendations. 

The  remaining  report  is  organized  as  follows.  Commercial  adoption,  which  drives 
availability  of  cost-effective  technology  in  the  marketplace,  is  discussed  in  Section  2.  A 
variety  of  DoD-speciflc  challenges,  such  as  information  security,  cyberwarfare  and 
training  are  addressed  in  Section  3.  Timing  issues  for  DoD  are  important,  and  the 
adoption  timing  is  a  subtle  choice,  involving  many  elements  of  a  complex  information 
“ecosystem”  -  we  address  these  issues  in  Section  4.  Section  5  summarizes  our  findings 
and  makes  three  recommendations,  two  short-term  and  one  longer  term.  Section  6 
concludes  the  report  and  Section  7  provides  an  annotated  list  of  sources  consulted  in  the 
study.  Appendix  A  provides  brief  biographies  of  the  authors,  and  Appendix  B  provides 
documentation  of  some  configuration  and  software  support  for  IPv6  in  a  consumer 
operating  system  (Apple  Mac  OS  X,  10.6  -  “Snow  Leopard”).  The  key  observation  is 
that  the  management  and  configuration  software  is  immature  for  this  client  platform. 
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2.0  Methods,  Assumptions,  and  Procedures 


The  commercial  Internet  is  organized  as  a  federation  of  Internet  Service  Providers  (ISPs), 
of  various  sizes  and  business  models.  All  ISPs  possess  groups  of  routers  and  links  of 
various  capacities  and  geographic  spans.  Business  models  may  include  home  access, 
business  services,  or  long  haul  carrier  businesses  (e.g.,  transcontinental  or  international  IP 
traffic  carriage).  To  maximize  use  of  real  estate  and  infrastructure  such  as  fibers,  carriers 
route  long-haul  traffic  using  the  highest  capacity  links  (10-40  Gigabits  per  second),  and 
switch  as  many  of  these  at  a  single  physical  location  as  possible.  Large  carrier  routing 
platforms  have  aggregate  capacities  of  multiple  terabits  per  second  and  are  currently 
capable  and  equipped  for  operating  IPv6  at  more  or  less  full  performance.  Multiple 
commercial  carriers  have  been  operating  IPv6  internally  for  over  two  years.  Broadband 
service  providers  such  as  Comcast  have  announced  availability  of  IPv6  for  their 
wholesale  customers  (see 

http : / / WWW . internetnews . com/ infra/ article. phpr / 3825696/ Cornea st+Embr aces + 

IPv6 .  htm).  but  are  running  dual-stack.  Some  commercial  network  providers,  then,  are 
ready  to  offer  IPv6. 

Turning  our  attention  now  to  hosts,  the  key  issue  for  a  host  that  is  attached  to  a 
network  that  can  run  IP  is  whether  it  has  a  software  system  that  can  interact  with  the 
version  (or  versions)  of  the  IP  protocol  that  other  systems  are  using.  For  example,  if  all 
other  systems  attached  to  the  network  are  running  IPv4  software,  and  the  routers  support 
IPv4,  and  the  host  is  running  IPv6,  then  it  has  no  systems  with  which  it  can  exchange 
packets.  If  the  network  supports  IPv6  but  there  are  no  remote  hosts  with  software 
supporting  IPv6,  then  there’s  effectively  a  route  to  nowhere.  If  there  are  remote  hosts  that 
can  operate  IPv6,  they  can  use  the  IPv4  network  to  carry  traffic  through  a  so-called 
tunnel.  Therefore  it  is  crucially  important  that  host  software  support  IPv6  if  a  computer 
network  is  to  form.  This  software  support  is  found  in  the  operating  system  software  of  a 
computer  host,  such  as  Microsoft’s  Windows  XP,  Windows  Vista  and  Windows  7, 
Apple’s  Mac  OS,  and  open  source  operating  systems  such  as  Linux  and  OpenBSD. 
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2.1  DoD-Specific  Issues 

There  are  a  variety  of  issues  with  IPv6  deployment  peeuliar  to  the  U.S.  Department  of 
Defense,  and  the  protoeol  path  versus  DoD  needs. 

2.1.1  Compatibility  with  Legacy  Equipment 

A  first  coneern  is  eompatibility  with  legaey  equipment  (a  direet  eonsequenee  of  long 
aequisition  lead  times)  as  well  as  long  shelf  life.  A  subtly  related  issue  is  training  and 
manpower  -  teehnieal  training  takes  time  to  develop  and  mature,  and  must  eneompass 
both  legacy  networks  as  well  as  newly  deployed  or  deploying  technologies.  For 
example,  familiarity  with  IPv4  and  IPv6,  as  well  as  the  configuration  and  management 
of  dual-stack  implementations  must  be  addressed  in  technical  training.  A  significant 
challenge  to  DoD  may  arise  as  a  consequence  of  lack  of  trained  people  to  configure  and 
manage  new  deployed  network  technologies. 

2.1.2  Compatibility  with  DoD  Network 

A  second,  related  issue  is  compatibility  with  the  DoD  Network  Centric  Warfare 
(“netcentricity”)  visions.  Examples  include  the  overarching  Global  Information  Grid  and 
the  service-specific  netcentricity  projects  such  as  the  Navy’s  FORCENet.  Akey 
characteristic  of  these  architectures  is  that  they  are  service  oriented  architectures  (SOAs), 
which  are  characterized  by  their  reliance  on  composition  of  distributed  “services”  such  as 
those  for  information  naming,  retrieval  and  dissemination.  SOAs,  as  overlays  running 
over  existing  networks,  should  be  able  to  run  as  well  on  IPv6  as  IPv4;  in  principle.  The 
implication  is  that  any  protocol  transition  should  be  transparent  to  applications  that 
employ  such  as  an  architecture. 

2.1.3  Costs  and  Overheads 

A  third  important  issue  is  money.  For  example,  while  IPv6  capabilities  are  mandated, 
there  are  many  costs  and  overheads  and  it  is  not  clear  that  these  have  been  adequately 
budgeted  for  and  funded.  Costs  include  the  training  and  staffing  discussed  earlier. 

2.1.4  Types  of  Network 

A  fourth  important  issue  is  the  types  of  networks  in  common  use  in  the  DoD.  These 
include  satellite  communications  networks  (which  are  difficult  to  update  once  deployed 
and  have  long  lead  times)  as  well  as  tactical  networks.  Wireless  links  are  a  key  part  of 
many  of  these  networks  as  many  parts  of  the  DoD  are  constantly  “on  the  move” 
(consider,  for  example.  Air  Force  networks)  and  only  wireless  communication  supports 
these  operations.  For  slow  speed  wireless  links  the  overheads  of  IPv6  may  prove 
significant. 
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2.1.5  Security 

A  final  issue,  and  an  issue  of  primary  importance,  is  information  assurance  and  the  issue 
of  network  security  more  generally.  Computer  networking  has  become  an  important  part 
of  modern  warfare,  ranging  from  situational  awareness  in  the  battlespace  to  logistics. 
Disruptions  to  these  networks  impair  warfighting  capabilities,  and  if  communications 
security  is  not  maintained,  can  lead  to  information  leakage  and  its  negative  consequences. 
As  some  actors  have  already  signaled  their  intentions  to  employ  cyberwarfare  both  alone 
and  in  concert  with  kinetic  warfare,  it  is  clear  that  U.S.  networks  must  be  secure,  and 
offensive  capabilities  may  be  required  as  well.  As  many  information  assurance  matters 
involve  the  National  Security  Agency  (NSA),  IPv6  plans  must  take  into  account  NSA 
Certification  and  availability  of  approved  devices  such  as  the  High  Assurance  IP 
Encryptor  (HAIPE)  for  IPv6. 

2.2  Timing 


Figure  2:  Deployment  “S-curve” 


Eigure  2  illustrates  an  “S-curve”,  used  to  represent  the  fraction  of  users  who  have 
transitioned  from  IPv4  to  IPv6.  The  key  attribute  of  the  S-curve  is  the  time  at  which  the 
sudden  increase  in  adoption  occurs.  Before  this  point,  adoption  is  slow,  and  after  it,  the 
remaining  IPv4  users  are  a  small  and  decreasing  percentage  of  users.  It  is  important  to 
understand  what  IPv6  transition  means:  it  is  the  point  where  the  IPv6  protocol  is  the 
primary  means  used  for  computer  networking.  If  mismeasured,  counts  might  use  metrics 
such  as:  (1)  routers  with  IPv6  capability,  (2)  hosts  with  IPv6  stacks,  or  even  (3)  host 
operating  systems  designed  to  prefer  IPv6  (if  present).  These  would  result  in  a  gross 
overestimate  of  operational  IPv6,  as  the  IPv6  ecosystem  (web  services,  IPv6  to  the  home, 
IPv6  wireless  hotspots)  has  not  been  fully  populated,  and  all  of  these  are  necessary  for  the 
majority  of  Internet  users.  Based  on  data  from  Google  in  their  IPv6  deployment  [11,  15], 
in  early  2010  we  remain  on  the  fiat,  pre-increase  portion  of  the  curve.  Based  on  Google’s 
data.  Prance  is  the  furthest  along  in  transition  to  IPv6,  driven  largely  by  a  single  early  ISP 
adopter  for  the  technology  (Pree). 
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Many  elements  are  aligned  for  a  sudden  increase  in  IPv6  connectivity: 

1 .  Windows  7  and  Mac  OS  X  turn  on  IPv6  by  default,  and  prefer  it  at  boot  time  if 
available  (most  users  are  unaware  that  it  is  turned  on  and  might  be  surprised  to 
find  that  it  is  active  at  tum-on;  this  may  permit  local  networking  that  is 
unobserved). 

2.  Most  universities  have  localized  “islands”  of  IPv6,  and  there  is  interconnection  of 
these  islands  via  networks  such  as  Internet2.  Universities  tend  to  be  early 
adopters,  with  an  important  side  effect:  they  set  student  expectations.  As  these 
students  leave  the  universities  and  take  positions  in  government  and  the 
commercial  world  they  may  expect  IPv6  connectivity. 

3.  Major  broadband  providers  such  as  Comcast  have  been  operating  IPv6  internally 
for  several  years,  and  have  recently  announced  IPv6  availability  for  consumers, 
presumably  to  gain  an  advantage  in  the  competitive  broadband  marketplace  (cable 
versus  DSL/FiOS). 

4.  Specialized  ISPs  such  as  Hurricane  Electric  have  arisen  to  offer  IPv6  services. 

5.  Some  Web  service  providers,  notably  Google,  have  been  strongly  advocating 
transition  to  IPv6,  and  have  put  “skin  in  the  game”  by  deploying  IPv6 
connectivity  to  their  various  web  services.  Unlike  many  other  actors  in  the 
ecosystem,  Google  has  financial  incentives  to  transition  to  IPv6,  since  network 
address  translators  may  make  services  more  difficult  to  deploy  and  may  interfere 
with  the  precision  of  targeting  personalization  and  advertising. 


Effect  of  legacy  systems 


Figure  3:  Key  pressures  leading  to  onset  of  rapid  deployment 


6 


There  are  also  some  logistieal  barriers,  in  partieular  the  large  deployed  infrastrueture  of 
IPv4  (e.g.,  for  wireless  aeeess  in  hotels)  and  Network  Address  Translators,  whieh  are 
often  eombined  with  paeket-filtering  firewall  and  router  funetionality  in  home 
deployments.  Figure  3  indieates  the  effeets  of  some  of  these  faetors. 

For  DoD,  the  timing  issues  are  eomplex.  On  the  one  hand,  there  is  the  natural 
desire  to  maintain  teehnology  leadership.  On  the  other  hand,  as  diseussed  earlier,  seeurity 
eonsiderations  are  of  greater  eoneem  in  DoD  than  in  the  eommereial  world,  not  least  due 
to  the  existenee  of  well-funded  nation-state  adversaries  as  well  as  eriminal  elements  that 
may  or  may  not  serve  as  proxies  for  nation-states. 

This  issue  is  important  beeause  DoD  must  gain  maturity  with  seeurity  issues  at 
least  as  fast  as  adversaries,  in  both  the  defensive  and  offensive  domains,  or  be  put  at  a 
disadvantage  during  and  after  the  transition.  In  the  next  Seetion,  3.0  Results  and 
Diseussions  and  4.0  Reeommendations,  we  propose  a  strategy  for  preparing  for 
transition. 
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Figure  4:  DoD  Timing  Strategies 
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There  is  risk,  however,  in  wholesale  transition  before  sueh  preparation  is  eomplete. 
IPv6  addresses  require  new  eode  in  programs  where  eonneetions  are  established  and 
paeket  addresses  are  examined,  beeause  the  data  objeets  are  of  different  size  (16  bytes 
versus  4  bytes).  Code  ean  be  modified  to  be  IPv6-only  or  to  support  dual-stack  (IPv4  and 
IPv6)  but  either  dual-stack  or  IPv6-only  code  represent  immature  code  paths,  with 
potential  opportunities  for  malice.  These  immature  code  paths  affect  any  code  that 
requires  changes  for  IPv6,  and  will  affect  both  application  code  and  tools.  This  latter 
issue,  that  of  tools,  is  of  particular  concern  since  system  administration  practices  (such  as 
the  use  of  security  appliances)  depend  heavily  on  tools  for  network  management, 
diagnosis  and  protection.  Administrators  will  require  training  and  familiarity  gained 
through  experience  to  be  effective  with  new  tools,  e.g.,  for  configuring  IPv6  addresses, 
specifying  IPv6  filtering  rules,  and  configuring  temporary  measures  such  as  “6to4”  IPv6 
in  IPv4  encapsulation  (used  to  tunnel  IPv6  over  IPv4  -  see  RFC3056). 
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3.0  Results  and  Discussion 


3.1  Finding  1 

Router  performance  is  not  an  issue.  Industry  is  managing  to  keep  performanee  high  in 
spite  of  larger  addresses  and  larger  routing  tables.  Hardware  capabilities  such  as 
Application-Specific  Integrated  Circuits  (ASICs)  coupled  with  specialized  memory 
technologies  appear  to  be  adequate  for  core  routers.  The  impacts  of  extensible  headers  are 
unclear  but  will  only  be  an  issue  if  such  headers  are  widely  used. 

3.2  Finding  2 

IPv6  does  not  address  all  IPv4  security  issues  and  further,  may  introduce  new  IPv6 
issues.  Security  issues  can  be  formulated  in  a  framework  such  as  “CIA”,  for 
Confidentiality,  Integrity  and  Availability.  Many  of  these  issues  are  the  same  for  both 
protocols,  e.g.,  application  layer  vulnerabilities  dominate  those  at  the  network  layer,  and 
reconnaissance  will  continue  although  methods  will  change.  As  noted  by  Vyncke[14] 
public  servers  will  still  need  to  be  DNS  reachable  and  to  overcome  the  difficulty  of 
remembering  the  long  IPv6  addresses,  administrators  may  use  easy-to-remember 
addresses  -  Vyncke  gives  :  :  FO  OD  and  :  :  C5C0  (he  works  for  Cisco)  as  examples. 

While  IPv6  integrates  the  security  features  of  IP  Security  (IPsec)  into  the  standard 
protocol,  neither  is  the  use  of  these  features  mandated  nor  does  it  ease  the  use  and 
configuration  of  the  cryptographic  protections  IPv6  security  offers.  For  example  it  does 
not  overcome  the  deployment  and  operational  challenges  of  public-key  infrastructures.  It 
is  well  known  that  cryptography  is  not  security  -  it  is  instead  a  well-founded  building 
block  for  protocols  to  protect  confidentiality  and  check  integrity.  There  are  some  other 
issues  with  securing  all  flows  with  IPsec,  also  noted  by  Vyncke  -  notably  those  endpoints 
and  end-users  must  be  trusted  because  firewalls  and  ACls  are  blinded,  as  is  Netflow- 
based  network  telemetry. 

As  with  IPv4,  IPv6  security  cannot  protect  against  availability  threats  such  as 
denial  of  service  attacks  (see  for  example  the  tools  Gtunneldos,  4to6ddos  and 
ipv6f  *ck),  and  can  make  no  guarantees  about  its  own  implementation  (e.g.,  that  an 
assumption  of  randomness  is  actually  met).  This  latter  point,  implementation,  is  a 
particular  challenge  as  IPv6  is  a  software  system  and  therefore  subject  to  all  of  the  “bugs” 
characteristic  of  software  systems,  including  some  exploitable  for  attacks.  As  a  somewhat 
interesting  example,  the  security-focused  OpenBSD  open  source  operating  system  was 
penetrated  by  an  IPv6  implementation  bug  in  2007. 
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3.3  Security  Issues 


Other  important  security  issues  are  raised  by  dual-stack  implementations  and 
tunnels.  Dual-stack  implementations  have  the  (unfortunate)  property  that  they  create  an 
attack  surface  for  applications  that  consists  of  both  IPv6  and  IPv4.  The  fact  that  IPv6  is 
enabled  by  default  creates  opportunities  for  an  attacker  sending  Router  Advertisements  to 
configure  your  host  to  IPv6  and  the  attack  surface  is  opened.  In  Appendix  B,  we  have 
included  documentation  from  the  MacOS  user  manual  that  illustrates  the  state  of  IPv6 
implementations  (inet  6),  as  well  as  two  other  tools,  gif  (used  for  tunneling)  and  st  f 
(an  interface  to  a  more  specific  IPv6  over  IP4  tunneling  capability).  While  these 
tunneling  solutions  are  intended  as  temporary  measures,  the  deployment  “S  Curve”  of 
Figure  2  suggests  that  these  transition  mechanisms  will  persist  for  a  long  time. 

Configuration  and  management  will  introduce  new  risks,  for  example  in  IPv6 
address  allocation  configurations  using  MAC  addresses  that  allow  attackers  to  deduce 
machine  types  and  some  network  configuration  information.  There  is  no  security 
mechanisms  built  into  the  discovery  protocol. 
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3.4  Finding  3 


Existing  DARE  A  net-centric  research  programs  are  generally  architecturally  compatible 
with  IPv6,  although  additional  software  may  be  needed.  A  survey  of  DARPA  network¬ 
centric  programs  was  performed  for  this  study  and  is  summarized  in  Table  1. 

Table  1:  DARPA  Net-centric  Programs 


Program 

DARPA 

Office 

Compatible 

IPv4? 

Compatible 

IPv6? 

SAPIENT 

IPTO 

Yes 

Yes^ 

Maingate 

STO 

Yes 

Yes 

Control  Plane 

STO 

Yes 

Yes^ 

lAMANET 

STO 

No* 

No* 

CORONET 

STO 

Yes 

Yes 

MNP 

STO 

Yes 

Yes^ 

DTN 

STO 

Yes 

Yes 

Connectionless 

STO 

Yes 

Yes'' 

WNaN 

STO 

Yes 

Yes 

LANdroids 

IPTO 

Yes 

Yes 

#  Architecturally  compatible; 
may  reqixlre  additional  software 

*  Reachback  via  gateway 


DARPA  programs  generally  address  fundamental  problems,  and  the  impact  of 
transitioning  capabilities  into  military  IPv6  networks  will  primarily  be  software 
modifications  (if  any  are  needed).  For  example,  the  DARPA/IPTO  SAPIENT  program 
might  require  an  additional  protocol  module  for  IPv6,  as  would  the  DARPA/STO 
Disruption  Tolerant  Networking  program.  Other  programs  such  as  DARPA/STO 
Wireless  Network  after  Next  (WNaN),  DARPA/IPTO  LANdroids  and  DARPA/STO 
CORONET  should  be  unaffected.  The  additional  overhead  of  larger  addresses  and 
headers  for  IPv6  may  affect  performance  in  wireless  networks  such  as  Mobile  Ad-hoc 
Networks  (MANETs). 
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3.5  Finding  4 

IPv6  penetration  today  is  very  low,  with  a  slow  rate  of  adoption.  Data  from 
Google  [15]  show  that  from  September  2008  to  September  2009,  the  year  over  year 
growth  (Fig.  2  of  [15])  was  35%,  but  based  on  Google’s  metrics  about  0.25%  of  users  had 
working  IPv6.  Based  on  when  connections  were  made  to  Google  IPv6  web  services,  they 
also  conclude  (based  on  a  higher  number  on  weekends)  that  there  is  more  available  from 
home  than  in  the  workplace.  The  predominant  connectivity  type  is  6to4,  followed  by 
“native/tunnel/unknown”,  with  a  tiny  fraction  of  connectivity  due  to  Teredo  and 
ISATAP.  The  predominant  operating  systems  are  MacOS  and  Windows  Vista.  If  we 
extrapolate  their  35%  growth  rate  to  plot  an  exponential  curve  (rather  than  the  “S  curve” 
we  believe  will  characterize  deployment)  it  will  take  until  2028  for  IPv6  to  become  the 
dominant  protocol. 

Some  commercial  firms,  notably  Google,  have  incentives  to  transition,  such  as 
improving  the  user  experience  (e.g.,  by  interacting  directly  with  a  user  machine  rather 
than  through  a  NAT).  Major  Internet  Service  Providers  such  as  Comcast  have  announced 
an  IPv6  deployment  plan,  and  the  latest  versions  of  consumer  operating  system  products 
(e.g.,  Microsoft  Windows  7,  Apple  Mac  OS  10.6  “Snow  Leopard”  and  various  instances 
of  the  open  source  operating  systems  such  as  Ubuntu  Linux)  incorporate  IPv6  and,  in 
fact,  prefer  routing  by  IPv6  if  it  is  present.  Other  operating  systems  (Windows  XP, 
NetBSD,  OpenBSD,  some  Linuxes,  FreeBSD)  support  IPv6,  but  not  as  the  default  option. 

Even  presuming  an  “S-curve”  upsweep  in  IPv6  penetration  occurs  (e.g.,  in  2011 
or  2012)  there  will  be  a  huge  installed  base  of  IPv4-only  equipment,  including  home 
routers,  devices  in  small-office/home-office  (SOHO)  settings,  and  relatively  recent 
deployments  in  settings  accessed  by  consumers  such  as  hotel  rooms  and  coffee  shops 
where  the  existing  equipment  works  well  enough  -  and  produces  enough  revenue  -  that 
additional  capital  expenses  would  be  hard  to  justify.  For  example,  the  Verizon  FiOS 
wireless  broadband  routers  do  not  support  native  IPv6  -  tunneling  over  IPv4  is  required. 
Also,  no  compelling  IPv6-only  applications  have  yet  emerged,  with  the  possible 
exception  of  Microsoft’s  “MeetingSpace”. 
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3.6  Finding  5 


IPv6  deployment  appears  to  be  proceeding  more  rapidly  outside  of  the  United  States. 
Based  on  data  from  JTF-GNO,  Table  2  shows  the  rank  and  percentage  of  currently 
assigned  IPv6  address  blocks  for  the  top  10  allocations  (about  96%  of  the  total): 

Table  2:  Assigned  IPv6  addresses 


Country 

% 

Brazil 

47.25 

US 

10.77 

Germany 

7.03 

Japan 

6.00 

France 

5.99 

Australia 

5.94 

European  Union 

4.43 

South  Korea 

3.74 

Italy 

3.00 

Taiwan 

1.66 

Data  from  Google  (interpreting  Figures  6  and  7  from  [15])  indicate  that  the  top  10 
countries  by  ratio  of  working  IPv6  are  Russia,  France,  Ukraine,  China,  US,  Poland, 
Sweden,  Canada,  Netherlands  and  Japan.  As  a  better  indicator  of  working  infrastructure, 
if  the  non-relayed  (i.e.,  no  6to4  or  Teredo,  which  could  be  deployed  by  users  with  no 
local  network  infrastructure,  leaving  “native/tunnel/unknown”  and  ISATAP) 
working  IPv6s  are  extracted,  the  top  10  are  France,  China,  Sweden,  Netherlands,  US, 
Japan,  Poland,  Russia,  Canada  and  Ukraine.  While  most  autonomous  systems  (ASes) 
with  large  IPv6  connectivity  are  universities  or  research  institutions  (3  in  China,  2  in  the 
US,  according  to  Tables  1  and  2  of  [15])  the  Free  AS  (AS12322)  in  France  generates  a 
large  percentage  of  French  IPv6  connectivity  as  measured  by  Google’s  methodology. 
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3.7  Finding  6: 


Neither  IPv6  performance  nor  the  interaction  of  IPv6  features  with  wireless  network 
architectures  are  well  understood  in  mobile,  wireless  networks.  This  topic  is  particularly 
important  in  tactical  networks,  which  are  almost  exelusively  mobile  and  wireless.  For 
example,  many  proposed  future  military  networks  sueh  as  that  of  the  Army’s  Future 
Combat  System  (FCS),  are  mobile  ad  hoe  networks  (MANETs)  and  yet  there  is  limited 
praetieal  experienee  with  MANETs  and  their  performanee.  Eurther,  the  interaetion 
between  IPv6  and  mobility  (e.g.,  “eare  of’  addresses,  ete.)  is  still  undergoing  study  in  the 
standardization  proeess,  with  multiple  Internet  Engineering  Task  Eoree  (IETF)  study 
groups,  e.g.,  I6ng  for  IEEE  802.16,  trying  to  resolve  teehnieal  issues.  Some  of  these 
diffieulties  appear  due  to  the  IPv6  standard  being  developed  prior  to  the  inereasing 
presenee  of  mobile  and  wireless  deviees  sueh  as  netbooks  and  smartphones,  but  these 
eonsumer  deviees  might  be  eonsidered  representative  of  ehallenges  to  be  faeed  in  military 
taetieal  networks. 
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4.0  Recommendations 


4.1  Recommendation  1 

DARPA  should  consider  initiating  a  program  or  series  of programs  focused  on  IPv6 
security  appliances,  such  as  firewall/gateways  and  intrusion  detection  systems.  A  well- 
documented,  open  source,  reference  IPv6  or  IPv6/IPv4  (dual-stack)  firewall 
implementation  engineered  to  the  highest  software  engineering  standards  and  red-teamed 
by  multiple  capable  red  teams  to  produce  a  definitive  (and  transitional)  implementation 
(e.g.,  one  which  defines  limits  on  continuation  headers)  will  stimulate  new  products  in 
the  commercial  world,  either  using  the  DARPA  code  base  or  augmenting  it.  It  would  find 
immediate  application  in  NIPR/public  Internet  gateways.  Advances  possible  in  such  a 
program  would  include  highly  usable  policy  expression  languages  and  tools  to  translate 
such  languages  into  low-level  filtering  and  analysis  specifications,  coordination  systems 
to  ensure  that  a  set  of  firewalls  are  enforcing  the  same  policy,  and  automatic  filter 
adaptation  (“intelligent  firewall”)  based  on  machine  learning  and  feedback. 

4.2  Recommendation  2 

DARPA  should  consider  initiating  a  breakaway  effort  in  creating  novel,  highly  usable  and 
well-documented  software  tools  for  IPv6  diagnosis,  configuration  and  management. 

This  programmatic  thrust  would  include  tools  to: 

•  Automate  IPv6  conversions  to  insure  they  end  up  with  a  safe  default 
configuration; 

•  Use  cognitive  techniques  to  diagnose  security  problems  and  recommend  fixes; 
and 

•  Automate  new  IPv6  configuration  setups  to  avoid  security  flaws  such  as  48-bit 
host  addresses  based  on  Ethernet  MACs  (by,  for  example,  initially  assigning  truly 
random  host  numbers). 

Better  tools  would  have  the  additional  side  effect  of  easing  training  and  thus  the 
challenges  associated  with  a  shortage  of  IPv6-trained  personnel. 

4.3  Recommendation  3 

DARPA  should  consider  initiating  a  program  or  series  of programs  focused  on  IPv6 
mobility/IPv6  wireless.  Particular  issues  to  be  addressed  include  exploratory  performance 
studies,  autoconfiguration  overheads  and  autoconfiguration  requirements.  For  example, 
IEEE  802.16  (WiMAX)  Wireless  MANs  have  problems  with  IPv6  autoconfiguration  due 
to  the  802.16  Medium  Access  Control  definitions  in  particular  its  non-support  for  native 
multicast.  Research  is  necessary  on  networks  intended  for  military  challenges  not 
generally  encountered  in  civilian  settings,  such  as  satellite  networks  and  mobile  ad-hoc 
networks. 
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5.0  Conclusions 


DARPA  should  consider  revolutionary  programs  to  overeome  diffieulties  with  IPv6 
through  inereased  automation,  leveraging  DARPA  advanees  in  eognitive  systems. 
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IPv6 
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IP 
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NATs 
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“CIA” 

IPsec 
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SOHO 

ASes 

PCS 

IEEE 

ISAT 
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Department  of  Defense 

Internet  Protoeol,  Version  4 

Internet  Protoeol,  Version  6 

Defense  Advanced  Projects  Research  Agency 

Internet  Protocol 

Mobile  Ad-hoc  Network 

Network  Address  Translators 

Dynamic  Host  Configuration  Protocol 

Internet  Service  Providers 

Service  Oriented  Architectures 

National  Security  Agency 

High  Assurance  Internet  Protocol  Encryptor 

Application-Specific  Integrated  Circuits 

Confidentiality,  Integrity,  and  Availability 

Internet  Protocol  Security 

Wireless  Network  after  Next 

Small-office/home-office 

Autonomous  Systems 

Puture  Combat  System 

Internet  Engineering  Task  Porce 

Information  Science  and  Technology 

Board  on  Army  Science  and  Technology 
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Appendix  B 

IPv6  Software  Doeumentation 


NAME 

inet6  —  Internet  protocol  version  6  family 

SYNOPSIS 

#include  <sys/types . h> 

#include  <netinet/in . h> 

DESCRIPTION 

The  inet6  family  is  an  updated  version  of  inet(4)  family.  While  inet(4)  implements  Internet  Protocol 
version  4,  inet6  implements  Internet  Protocol  version  6. 

inet6  is  a  collection  of  protocols  layered  atop  the  Internet  Protocol  version  6  (IPv6)  transport  layer,  and 
utilizing  the  IPv6  address  format.  The  inet6  family  provides  protocol  support  for  the  SOCK_STREAM, 
SOCK_DGRAM,  and  SOCK_RAW  socket  types;  the  SOCK_RAW  interface  provides  access  to  the  IPv6  protocol. 

ADDRESSING 

IPv6  addresses  are  16  byte  quantities,  stored  in  network  standard  byteorder.  The  include  file 
(netinet/in  .  h)  defines  this  address  as  a  discriminated  union. 

Sockets  bound  to  the  inet6  family  utilize  the  following  addressing  structure: 

struct  sockaddr_in6  { 

u_int8_t  sin 6 

u_int8_t  sin 6 

u_intl6_t  sin 6 

u_int32_t  sin 6 

struct  in6_addr 
u_int32_t  sin 6 

}; 

Sockets  may  be  created  with  the  local  address  “ :  :  ”  (which  is  equal  to  IPv6  address  0:0:0:0:0:0:0:0) 
to  affect  “wildcard”  matching  on  incoming  messages. 

The  IPv6  specification  defines  scoped  addresses,  like  link-local  or  site-local  addresses.  A  scoped  address  is 
ambiguous  to  the  kernel,  if  it  is  specified  without  a  scope  identifier.  To  manipulate  scoped  addresses  prop¬ 
erly  from  the  userland,  programs  must  use  the  advanced  API  defined  in  RFC2292.  A  compact  description  of 
the  advanced  API  is  available  in  ip  6(4).  If  a  scoped  address  is  specified  without  an  explicit  scope,  the  ker¬ 
nel  may  raise  an  error.  Note  that  scoped  addresses  are  not  for  daily  use  at  this  moment,  both  from  a  specifi¬ 
cation  and  an  implementation  point  of  view. 

The  KAME  implementation  supports  an  extended  numeric  IPv6  address  notation  for  link-local  addresses, 
like  “fe80 :  :  l%deO”  to  specify  “fe80::l  on  deO  interface”.  This  notation  is  supported  by 
getaddrinf o(3)  and  getnameinf o(3).  Some  of  normal  userland  programs,  such  as  telnet(l)  or 
ftp(l),  are  able  to  use  this  notation.  With  special  programs  like  ping 6(8),  you  can  specify  the  outgoing 
interface  by  an  extra  command  line  option  to  disambiguate  scoped  addresses. 

Scoped  addresses  are  handled  specially  in  the  kernel.  In  kernel  structures  like  routing  tables  or  interface 
structures,  a  scoped  address  will  have  its  interface  index  embedded  into  the  address.  Therefore,  the  address 
in  some  kernel  structures  is  not  the  same  as  that  on  the  wire.  The  embedded  index  will  become  visible 
through  a  PF_ROUTE  socket,  kernel  memory  accesses  via  kvm(3)  and  on  some  other  occasions.  HOW¬ 
EVER,  users  should  never  use  the  embedded  form.  Eor  details  please  consult  IMPLEMENTATION  supplied 
with  KAME  kit. 


_len; 

_family; 

_port ; 

_f lowinfo; 

sin6_addr; 

_scope_id; 
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PROTOCOLS 

The  i  nets  family  is  comprised  of  the  IPv6  network  protocol,  Internet  Control  M  essage  Protocol  version  6 
(lCMPv6),  Transmission  Control  Protocol  (TCP),  and  User  Datagram  Protocol  (UDP).  TCP  is  used  to 
support  the  S0CK_  STREAM  abstraction  while  UDP  is  used  to  support  the  S0CK_  DGRAM  abstraction.  Note 
thatTCP  and  UDP  are  common  to  i  net  (4)  and  i  net6.  A  raw  interface  to  IPv6  is  available  by  creating  an 
Internet  socket  of  type  SOCK  _  RAW.  The  ICM  Pv6  message  protocol  is  accessible  from  a  raw  socket. 

MIB  Variables 

A  number  of  variables  are  implemented  in  the  net.inet6  branch  of  the  s  y  s  c  1 1  (3)  M  IB .  In  addition  to  the 
variables  supported  by  the  transport  protocols  (for  which  the  respective  manual  pages  may  be  consulted),  the 
following  general  variables  are  defined: 

I  PV6CTL_  F  ORWARDI  NG  ( I p6. forward! ng )  Boolean:  enable/disable  forwarding  of  IPv6  packets. 

Also,  identify  if  the  node  is  acting  as  a  router.  Defaults  to  off. 

I  PV6CTL_  SENDREDI  RECTS  ( ip6. redirect)  Boolean:  enable/disable  sending  of  lCMPv6  redirects  in 

response  to  unforwardable  IPv6  packets.  This  option  is  ignored  unless  the 
node  is  routing  IPv6  packets,  and  should  normally  be  enabled  on  all  sys¬ 
tems.  Defaults  to  on. 

IPV6CTL_DEFFILIM  (ipG.hlim)  Integer:  default  hop  limit  value  to  use  for  outgoing  IPv6  pack¬ 

ets.  This  value  applies  to  all  the  transport  protocols  on  top  of  IPv6.  There 
areAPIsto  override  the  value. 

I  PV6CTL_  MAXF  RAGPACKETS  ( ipG.maxfragpackets)  Integer:  default  maximum  number  of  fragmented 

packets  the  node  will  accept.  0  means  that  the  node  will  not  accept  any 
fragmented  packets.  -1  means  that  the  node  will  accept  as  many  frag¬ 
mented  packets  as  it  receives.  The  flag  is  provided  basically  for  avoiding 
possible  DoS  attacks. 

I  P V6CTL_  ACCE PT_  RTADV  ( ip6.accept_rtadv )  Boolean:  enable/disable  receiving  of  lCMPv6  router 

advertisement  packets,  and  autoconflguration  of  address  prefixes  and 
default  routers.  The  node  must  be  a  host  (not  a  router)  for  the  option  to  be 
meaningful.  Defaults  to  off. 

I  PV6CTL_  KEEPF  Al  TFI  ( ipG.keepfaith )  Boolean:  enable/disable  "FAITH"  TCP  relay  IPv6-to- 

IPv4  translator  code  in  the  kernel.  Refer  f  a  i  t  h  (4)  and  f  a  i  t  h  d  (8)  for 
detail.  Defaults  to  off. 

I  PV6CTL_L0G_I  NTERVAL  ( ip6. 1 og_ interval )  Integer:  default  interval  between  IPv6  packet  forward¬ 

ing  engine  log  output  (in  seconds). 

IPV6CTL_FIDRNESTLIMIT  ( ipG.hdrnestlimit)  Integer:  default  number  of  the  maximum  IPv6  exten¬ 
sion  headers  permitted  on  incoming  IPv6  packets.  If  set  to  0,  the  node  will 
accept  as  many  extension  headers  as  possible. 

I  PV6CTL_  DAD_ COUNT  ( ip6.dad_count)  Integer:  default  number  of  IPv6  DAD  (duplicated 

address  detection)  probe  packets.  The  packets  will  be  generated  when 
IPv6  interface  addresses  are  configured. 

I  P  V6CTL_  AUT0_  F  L  OWL  ABE  L  ( ip6.auto_flowlabel )  Boolean:  enable/disable  automatic  Ailing  of  IPv6 

flowlabel  field,  for  outstanding  connected  transport  protocol  packets.  The 
field  might  be  used  by  intermediate  routers  to  identify  packet  flows. 
Defaults  to  on. 
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I  PV6CTL_DEFMCASTHLI  M  ( ip6.defmcasthlim )  Integer:  default  hop  limit  value  for  an  IPv6  multicast 

packet  sourced  by  the  node.  This  value  applies  to  all  the  transport  proto¬ 
cols  on  top  of  IPv6.  There  are  A  Pis  to  override  the  value  as  documented  in 
I  p6(4). 

I  PV6CTL_GI  F_HLI  M  ( ip6.gifhlim )  Integer:  default  maximum  hop  limit  value  for  an  IPv6 

packet  generated  by  g  I  f  (4)  tunnel  interface. 

I  PV6CTL_  KAMF_  VFRSI  ON  ( ip6.kame_version )  String:  identifies  the  version  of  KAM  E  IPv6  stack 

implemented  in  the  kernel. 

I  PV6CTL_  USF_  DFPRFCATFD  ( ip6.use_deprecated )  Boolean:  enable/disable  use  of  deprecated  address, 

specified  in  RFC2462  5.5.4.  Defaults  to  on. 

I  PV6CTL_  RR_  PRUNE  ( ip6.rr_prune)  Integer:  default  interval  between  IPv6  router  renumbering 

prefix  babysitting,  in  seconds. 

I  PV6CTL_  MAPPED_  ADDR  ( ip6.mapped_addr)  Boolean:  enable/disable  use  of  IPv4  mapped  address 

onAF_l  NET  6  sockets.  Defaults  to  on. 

I  PV6CTL_  RTEXPI  RE  ( ipB.rtexpire)  Integer:  lifetime  in  seconds  of  protocol -cloned  IP  routes 

after  the  last  reference  drops  (default  one  hour). 

I  PV6CTL_RTMI  NEXPI  RE  ( ipB.rtminexpire)  Integer:  minimum  value  of  ip. rtexpi re  (default  ten  sec¬ 
onds). 

I  PV6CTL_  RTMAXCACHE  ( ipB.rtmaxcache)  Integer:  trigger  level  of  cached,  unreferenced,  protocol- 

cloned  routes  which  initiates  dynamic  adaptation  (default  128). 

Inberacticn  bdvuaen  I  P\^Vv6  sxkds 

The  behavior  ofAF_l  NET6  TCP/UDP  socket  is  documented  in  RFC  2553.  Basically,  it  says  this: 

•  A  specific  bind  on  an  AF  _  I  NET6  socket  (bi  n  d  (2)  with  an  address  specified)  should  accept  IPv6  traffic 
to  that  address  only. 

•  If  you  perform  a  wildcard  bind  on  an  AF  _  I  NET6  socket  (bind  (2)  to  IPv6  address  :  :  ),  and  there  is  no 
wildcard  bind  AF_I  NET  socket  on  that  TCP/UDP  port,  IPv6  traffic  as  well  as  IPv4  traffic  should  be 
routed  to  that  AF  _  I  NET 6  socket.  IPv4  traffic  should  be  seen  as  if  it  came  from  an  IPv6  address  like 
:  :  f  f  f  f :  1 0 .  1 .  1 .  1 .  This  is  called  an  IPv4  mapped  address. 

•  If  there  are  both  a  wildcard  bind  AF_I  NET  socket  and  a  wildcard  bind  AF_I  NET6  socket  on  one 
TCP/UDP  port,  they  should  behave  separately.  IPv4  traffic  should  be  routed  to  the  AF_  I  NET  socket  and 
IPv6  should  be  routed  to  the  AF  _  I  NET  6  socket. 

However,  RFC2553  does  not  define  the  ordering  constraint  between  calls  to  bi  nd(2),  nor  how  IPv4 
TCP/UDP  port  numbers  and  IPv6  TCP/UDP  port  numbers  relate  to  each  other  (should  they  be  integrated  or 
separated).  Implemented  behavior  is  very  different  from  kernel  to  kernel.  Therefore,  it  is  unwise  to  rely  too 
much  upon  the  behavior  of  AF  _  I  NET6  wildcard  bind  sockets.  It  is  recommended  to  listen  to  two  sockets, 
onefor  AF  _  I  NET  and  another  for  AF  _  I  NET  6 ,  when  you  would  like  to  accept  both  IPv4  and  IPv6  traffic. 

It  should  also  be  noted  that  malicious  parties  can  take  advantage  of  the  complexity  presented  above,  and  are 
able  to  bypass  access  control,  if  the  target  node  routes  IPv4  traffic  to  AF  _  I  NET6  socket.  Users  are  advised 
to  take  care  handling  connections  from  IPv4  mapped  address  to  AF  _  I  NET  6  sockets. 

SEE  ALSO 

i  oc  1 1  (2),  socket  (2),  s  y  s  c  1 1  (3),  i  c  mp6  (4),  intro  (4),  i  p6  (4),  t  c  p  (4),  1 1  c  p  (4),  ud  p  (4) 
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STANDARDS 

Tatsuya  J  inmei  and  Atsushi  Onoe,  An  Extension  of  Format  for  IPv6  Scoped  Addresses,  internet  draft,  draft- 
ietf-ipngwg-scopedaddr-format-02.txt, June 2000,  work  in  progress materiai. 

HISTORY 

The  i  nets  protocoi  interfaces  are  defined  in  RFC2553  and  RFC2292.  The  impiementation  described 
herein  appeared  in  theWIDE/KAM  E  project. 


BUGS 

The  IPv6  support  is  subject  to  change  as  the  Internet  protocols  develop.  Users  should  not  depend  on  details 
of  the  current  implementation,  but  rather  the  services  exported. 

Users  are  suggested  to  implement  "version  independent"  code  as  much  as  possible,  as  you  will  need  to  sup¬ 
port  both  i  n  e  t  (4)  and  i  net  6. 
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NAME 

gif  —  generic  tunnel  interface 

SYNOPSIS 

pseudo-device  gif 
DESCRIPTION 

The  gif  interface  is  a  generic  tunnelling  pseudo  device  for  IPv4  and  IPv6.  It  can  tunnel  IPv[46]  traffic  over 
IPv[46].  Therefore,  there  can  be  four  possible  configurations.  The  behavior  of  gif  is  mainly  based  on 
RFC2893  IPv6-over-IPv4  configured  tunnel.  On  NetBSD,  gif  can  also  tunnel  ISO  traffic  over  IPv[46]  using 
EON  encapsulation. 

Each  gif  interface  is  created  at  runtime  using  interface  cloning.  This  is  most  easily  done  with  the 
if  conf  ig(8)  create  command  or  using  the  gifconfig_{interface)  variable  in  rc  .  conf(5). 

To  use  gif,  administrator  needs  to  configure  protocol  and  addresses  used  for  the  outer  header.  This  can  be 
done  by  using  gif  conf  ig(8),  or  SIOCSIFPHYADDR  ioctl.  Also,  administrator  needs  to  configure  proto¬ 
col  and  addresses  used  for  the  inner  header,  by  using  ifconfig(8).  Note  that  IPv6  link-local  address 
(those  start  with  fe80  :  :)  will  be  automatically  configured  whenever  possible.  You  may  need  to  remove 
IPv6  link-local  address  manually  using  if  conf  ig(8),  when  you  would  like  to  disable  the  use  of  IPv6  as 
inner  header  (like  when  you  need  pure  IPv4-over-IPv6  tunnel).  Einally,  use  routing  table  to  route  the  packets 
toward  gif  interface. 

gif  can  be  configured  to  be  ECN  friendly.  This  can  be  configured  by  IFF_LINK1. 

ECN  friendly  behavior 

gif  can  be  configured  to  be  ECN  friendly,  as  described  in  draft-ietf-ipsec-ecn-02  .  txt.  This  is 
turned  off  by  default,  and  can  be  turned  on  by  IFF_LINK1  interface  flag. 

Without  IFF_LINK1,  gif  will  show  a  normal  behavior,  like  described  in  REC2893.  This  can  be  summa¬ 
rized  as  follows: 

Ingress  Set  outer  TOS  bit  to  0 . 

Egress  Drop  outer  TOS  bit. 

With  IFF_LINK1,  gif  will  copy  ECN  bits  (0x02  and  0x01  on  IPv4  TOS  byte  or  IPv6  traffic  class  byte) 
on  egress  and  ingress,  as  follows: 

Ingress  Copy  TOS  bits  except  for  ECN  CE  (masked  with  Oxfe)  from  inner  to  outer.  Set  ECN 
CE  bit  to  0 . 

Egress  Use  inner  TOS  bits  with  some  change.  If  outer  ECN  CE  bit  is  1,  enable  ECN  CE  bit  on 
the  inner. 

Note  that  the  ECN  friendly  behavior  violates  REC2893.  This  should  be  used  in  mutual  agreement  with  the 
peer. 

Security 

Malicious  party  may  try  to  circumvent  security  Alters  by  using  tunnelled  packets.  Eor  better  protection,  gif 
performs  martian  Alter  and  ingress  Alter  against  outer  source  address,  on  egress.  Note  that  martian/ingress 
Alters  are  no  way  complete.  You  may  want  to  secure  your  node  by  using  packet  Alters.  Ingress  Alter  can  be 
turned  off  by  IFF_LINK2  bit. 
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Miscellaneous 

By  default,  gif  tunnels  may  not  be  nested.  This  behavior  may  be  modified  at  runtime  by  setting  the 
sysctl(8)  variable  net.link.gif.max_nesting  to  the  desired  level  of  nesting.  Additionally,  gif  tunnels  are 
restricted  to  one  per  pair  of  end  points.  Parallel  tunnels  may  be  enabled  by  setting  the  sysctl(8)  variable 
net.link.gifparallel_tunnels  to  1. 

SEE  ALSO 

inet(4),  inet6(4),  gifconfig(8) 

R.  Gilligan  and  E.  Nordmark,  "Transition  Mechanisms  for  IPv6  Hosts  and  Routers",  RFC2893,  August  2000, 
ftp://ftp.isi.edu/in-notes/rfc2893.txt. 

Sally  Floyd,  David  L.  Black,  and  K.  K.  Ramakrishnan,  IPsec  Interactions  with  ECN,  December  1999,  draft- 
ietf-ipsec-ecn-02.txt. 

HISTORY 

The  gif  device  first  appeared  in  WIDE  hydrangea  IPv6  kit. 


BUGS 

There  are  many  tunnelling  protocol  specifications,  defined  differently  from  each  other,  gif  may  not  interop¬ 
erate  with  peers  which  are  based  on  different  specifications,  and  are  picky  about  outer  header  fields.  For 
example,  you  cannot  usually  use  gif  to  talk  with  IPsec  devices  that  use  IPsec  tunnel  mode. 

The  current  code  does  not  check  if  the  ingress  address  (outer  source  address)  configured  to  gif  makes  sense. 
Make  sure  to  configure  an  address  which  belongs  to  your  node.  Otherwise,  your  node  will  not  be  able  to 
receive  packets  from  the  peer,  and  your  node  will  generate  packets  with  a  spoofed  source  address. 

If  the  outer  protocol  is  IPv4,  gif  does  not  try  to  perform  path  MTU  discovery  for  the  encapsulated  packet 
(DF  bit  is  set  to  0). 

If  the  outer  protocol  is  IPv6,  path  MTU  discovery  for  encapsulated  packet  may  affect  communication  over 
the  interface.  The  first  bigger-than-pmtu  packet  may  be  lost.  To  avoid  the  problem,  you  may  want  to  set  the 
interface  MTU  for  gif  to  1240  or  smaller,  when  outer  header  is  IPv6  and  inner  header  is  IPv4. 

gif  does  not  translate  ICMP  messages  for  outer  header  into  inner  header. 

In  the  past,  gif  had  a  multi-destination  behavior,  conhgurable  via  IFF_LINK0  flag.  The  behavior  was 
obsoleted  and  is  no  longer  supported. 

It  is  thought  that  this  is  not  actually  a  bug  in  gif,  but  rather  lies  somewhere  around  a  manipulation  of  an  IPv6 
routing  table. 
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NAME 


stf  —  6to4  tunnel  interface 

SYNOPSIS 

pseudo-device  stf 
DESCRIPTION 

The  stf  interface  supports  “6to4”  IPv6  in  IPv4  encapsulation.  It  can  tunnel  IPv6  traffic  over  IPv4,  as  speci¬ 
fied  in  RFC3056. 

For  ordinary  nodes  in  6to4  site,  you  do  not  need  stf  interface.  The  stf  interface  is  necessary  for  site  bor¬ 
der  router  (called  “6to4  router”  in  the  specification). 

Due  to  the  way  6to4  protocol  is  specified,  stf  interface  requires  certain  configuration  to  work  properly.  Sin¬ 
gle  (no  more  than  1)  valid  6to4  address  needs  to  be  configured  to  the  interface.  “A  valid  6to4  address”  is  an 
address  which  has  the  following  properties.  If  any  of  the  following  properties  are  not  satisfied,  stf  raises 
runtime  error  on  packet  transmission.  Read  the  specification  for  more  details. 

•  matches  2  0  02  :  xxyy :  zzuu  :  :/48  where  xxyy:zzuu  is  a  hexadecimal  notation  of  an  IPv4  address 
for  the  node.  IPv4  address  can  be  taken  from  any  of  interfaces  your  node  has.  Since  the  specification 
forbids  the  use  of  IPv4  private  address,  the  address  needs  to  be  a  global  IPv4  address. 

•  Subnet  identifier  portion  (48th  to  63rd  bit)  and  interface  identifier  portion  (lower  64  bits)  are  properly 
filled  to  avoid  address  collisions. 

If  you  would  like  the  node  to  behave  as  a  relay  router,  the  prefix  length  for  the  IPv6  interface  address  needs 
to  be  16  so  that  the  node  would  consider  any  6to4  destination  as  “on-link”.  If  you  would  like  to  restrict  6to4 
peers  to  be  inside  certain  IPv4  prefix,  you  may  want  to  configure  IPv6  prefix  length  as  “16  +  IPv4  prefix 
length”,  stf  interface  will  check  the  IPv4  source  address  on  packets,  if  the  IPv6  prefix  length  is  larger  than 
16. 

stf  can  be  configured  to  be  ECN  friendly.  This  can  be  configured  by  IFF_LINK1.  See  gif(4)  for  details. 

Please  note  that  6to4  specification  is  written  as  “accept  tunnelled  packet  from  everyone”  tunnelling  device. 
By  enabling  stf  device,  you  are  making  it  much  easier  for  malicious  parties  to  inject  fabricated  IPv6  packet 
to  your  node.  Also,  malicious  party  can  inject  an  IPv6  packet  with  fabricated  source  address  to  make  your 
node  generate  improper  tunnelled  packet.  Administrators  must  take  caution  when  enabling  the  interface.  To 
prevent  possible  attacks,  stf  interface  filters  out  the  following  packets.  Note  that  the  checks  are  no  way 
complete: 

•  Packets  with  IPv4  unspecified  addrss  as  outer  IPv4  source/destination  (0.0. 0.0/8) 

•  Packets  with  loopback  address  as  outer  IPv4  source/destination  (127.0.0.0/8) 

•  Packets  with  IPv4  multicast  address  as  outer  IPv4  source/destination  (224.0.0.0/4) 

•  Packets  with  limited  broadcast  address  as  outer  IPv4  source/destination  (255.0.0.0/8) 

•  Packets  with  subnet  broadcast  address  as  outer  IPv4  source/destination.  The  check  is  made  against  sub¬ 
net  broadcast  addresses  for  all  of  the  directly  connected  subnets. 

•  Packets  that  does  not  pass  ingress  filtering.  Outer  IPv4  source  address  must  meet  the  IPv4  topology  on 
the  routing  table.  Ingress  filter  can  be  turned  off  by  IFF_LINK2  bit. 

•  The  same  set  of  rules  are  appplied  against  the  IPv4  address  embedded  into  inner  IPv6  address,  if  the  IPv6 
address  matches  6to4  prefix. 

It  is  recommended  to  filter/audit  incoming  IPv4  packet  with  IP  protocol  number  41,  as  necessary.  It  is  also 
recommended  to  filter/audit  encapsulated  IPv6  packets  as  well.  You  may  also  want  to  run  normal  ingress  fil- 
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ter  against  inner  IPv6  address  to  avoid  spoofing. 

By  setting  the  IFF_LINK0  flag  on  the  stf  interface,  it  is  possible  to  disable  the  input  path,  making  the 
direct  attacks  from  the  outside  impossible.  Note,  however,  there  are  other  security  risks  exist.  If  you  wish  to 
use  the  configuration,  you  must  not  advertise  your  6to4  address  to  others. 

EXAMPLES 

Note  that  8504:0506  is  equal  to  1 3  3 . 4 . 5 . 6,  written  in  hexadecimals. 

#  ifconfig  neO  inet  133.4.5.6  netmask  OxffffffOO 

#  ifconfig  stfO  inet6  2002 : 8504 : 0506 : 0000 : aOO : 5aff : fe38 : 6f 86  \ 

prefixlen  16  alias 

The  following  configuration  accepts  packets  from  IPv4  source  9.1.0.0/16  only.  It  emits  6to4  packet  only 
for  IPv6  destination  2002;0901::/32  (IPv4  destination  will  match  9.1.0.0/16). 

#  ifconfig  neO  inet  9. 1.2. 3  netmask  OxffffOOOO 

#  ifconfig  stfO  inet6  2002  :  0901 : 0203 : 0000 : aOO : 5aff : fe38 : 6f 86  \ 

prefixlen  32  alias 

The  following  configuration  uses  the  stf  interface  as  an  output-only  device.  You  need  to  have  alternative 
IPv6  connectivity  (other  than  6to4)  to  use  this  configuration.  For  outbound  traffic,  you  can  reach  other  6to4 
networks  efficiently  via  stf.  For  inbound  traffic,  you  will  not  receive  any  6to4-tunneled  packets  (less  secu¬ 
rity  drawbacks).  Be  careful  not  to  advertise  your  6to4  prefix  to  others  (2002:8504:0506:  :/48),  and 
not  to  use  your  6to4  prefix  as  a  source. 

#  ifconfig  neO  inet  133.4.5.6  netmask  OxffffffOO 

#  ifconfig  stfO  inet6  2002 : 8504 : 0506 : 0000 : aOO : 5aff : fe38 : 6f86  \ 

prefixlen  16  alias  deprecated  linkO 

#  route  add  -inet6  2002::  -prefixlen  16  ::1 

#  route  change  -inet6  2002::  -prefixlen  16  ::1  -ifp  stfO 

SEE  ALSO 

gif(4),  inet(4),  inet 6(4) 

http : // WWW . 6bone .net/ 6bone_6to4 . html 
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HISTORY 

The  stf  device  first  appeared  in  WIDE/KAME  IPv6  stack. 


BUGS 

No  more  than  one  stf  interface  is  allowed  for  a  node,  and  no  more  than  one  IPv6  interface  address  is 
allowed  for  an  stf  interface.  It  is  to  avoid  source  address  selection  conflicts  between  IPv6  layer  and  IPv4 
layer,  and  to  cope  with  ingress  Altering  rule  on  the  other  side.  This  is  a  feature  to  make  stf  work  right  for 
all  occasions. 
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